Serving GPRS Support Node (SGSN) Overview

 

This chapter contains general overview information about the Serving GPRS Support Node (SGSN), including sections for:

•	Product Description

•	Network Deployments and Interfaces

•	SGSN Core Functionality

•	Features and Functionality

•	How the SGSN Works

•	Supported Standards

Product Description

The ASR 5000 provides a highly flexible and efficient Serving GPRS Support Node (SGSN) service to the wireless carriers. Functioning as an SGSN, the system readily handles wireless data services within 2.5G General Packet Radio Service (GPRS) and 3G Universal Mobile Telecommunications System (UMTS) data networks.

Important: Throughout this chapter the designation for the subscriber equipment is referred to in various ways: UE for user equipment (common to 3G/4G scenarios), MS or mobile station (common to 2G/2.5G scenarios), and MN or mobile node (common to 2G/2.5G scenarios involving IP-level functions). Unless noted, these terms are equivalent and the term used usually complies with usage in the relevant standards.

In a GPRS/UMTS network, the SGSN works in conjunction with radio access networks (RANs) and Gateway GPRS Support Nodes (GGSNs) to:

•	Communicate with home location registers (HLR) via a Gr interface and mobile visitor location registers (VLRs) via a Gs interface to register a subscriber’s user equipment (UE), or to authenticate, retrieve or update subscriber profile information.

•	Support Gd interface to provide short message service (SMS) and other text-based network services for attached subscribers.

•	Activate and manage IPv4, IPv6, or point-to-point protocol (PPP) -type packet data protocol (PDP) contexts for a subscriber session.

•	Setup and manage the data plane between the RAN and the GGSN providing high-speed data transfer with configurable GEA0-3 ciphering.

•	Provide mobility management, location management, and session management for the duration of a call to ensure smooth handover.

•	Provide various types of charging data records (CDRs) to attached accounting/billing storage mechanisms such as our SMC-based hard drive or a GTPP Storage Server (GSS) or a charging gateway function (CGF).

•	Provide CALEA support for lawful intercepts.

This chapter catalogs many of the SGSN key components and features for data services within the GPRS/UMTS environment. Also, a range of SGSN operational and compliance information is summarized with pointers to other information sources.

Platform Requirements

The SGSN service runs on a Cisco® ASR 5000 Series chassis running StarOS. The chassis can be configured with a variety of components to meet specific network deployment requirements. For additional information, refer to the Installation Guide for the chassis and/or contact your Cisco account representative.

Licenses

The SGSN is a licensed Cisco product and requires the purchase and installation of the SGSN Software License. Separate feature licenses may be required. Contact your Cisco account representative for detailed information on specific licensing requirements.

For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.

Network Deployments and Interfaces

The following logical connections maps indicate the SGSN’s ability to connect to both 2G (GSM BSS) and 3G (UMTS RAN) radio access networks, a mobile service center (MSC) and visitor location register (VLR), a home location register (HLR), a charging gateway (CG - sometimes referred to as a charging gateway function (CGF)), a GTPP storage server (GSS), a standalone GGSN, network devices in another PLMN, an SMS server center, and a standalone SGSN.

SGSN and Dual Access SGSN Deployments

SGSNs and GGSNs work in conjunction within the GPRS/UMTS network. As indicated earlier in the section on System Configuration Options, the flexible architecture of the ASR 5000 enables a single chassis to reduce hardware requirements by supporting integrated co-location of a variety of the GPRS/UMTS services.

A chassis can be devoted solely to SGSN services or the SGSN system can include any co-location combination, such as multiple instances of 2.5G SGSNs (configured as GPRS services); or multiple instances of 3G SGSNs (configured as SGSN services); or a combination of 2.5G and 3G SGSN to comprise a dual access SGSN.

Dual Access 2.5/3G SGSNs

SGSN/GGSN Deployments

The co-location of the SGSN and the GGSN in the same chassis facilitates handover. Again, it can be any type of SGSN, 2.5G or 3G, with the GGSN.

Co-located SGSN and GGSN

SGSN Logical Network Interfaces

The SGSN provides IP-based transport on all RAN and Core Network interfaces, in addition to the standard IP-based interfaces (Ga, Gn, Gp, Iu-PS). This means enhanced performance, future-proof scaling and reduction of inter-connectivity complexity. The all-IP functionality is key to facilitating evolution to the next generation technology requirements.

The SGSN provides the following functions over the logical network interfaces illustrated above:

•	Ga: The SGSN uses the Ga interface with GTP Prime (GTPP) to communicate with the charging gateway (CG, also known as CGF) and/or the GTPP Storage Server (GSS). The interface transport layer is typically UDP over IP but can be configured as TCP over IP for:

•	One or more Ga interfaces per system context, and

•	An interface over Ethernet 10/100 or Ethernet 1000 interfaces

The charging gateway handles buffering and pre-processing of billing records and the GSS provides storage for Charging Data Records (CDRs). For additional information regarding SGSN charging, refer to the Charging section.

•

IuPS: The SGSN provides an IP over ATM (IP over AAL5 over ATM) interface between the SGSN and the RNCs in the 3G UMTS Radio Access Network (UTRAN). RANAP is the control protocol that sets up the data plane (GTP-U) between these nodes. SIGTRAN (M3UA/SCTP) or QSAAL (MTP3B/QSAAL) handle IuPS-C (control) for the RNCs.

Some of the procedures supported across this interface are:

•	Control plane based on M3UA/SCTP

•	Up to 128 Peer RNCs per virtual SGSN. Up to 256 peers per physical chassis

•	SCTP Multi-Homing supported to facilitate network resiliency

•	M3UA operates in and IPSP client/server and single/double-ended modes

•	Multiple load shared M3UA instances for high-performance and redundancy

•	Works over Ethernet and ATM (IPoA) interfaces

•	Facilitates SGSN Pooling

•	RAB (Radio Access Bearer) Assignment Request

•	RAB Release Request

•	Iu Release Procedure

•	SGSN-initiated Paging

•

Common ID

•	Security Mode Procedures

•	Initial MN Message

•	Direct Transfer

•	Reset Procedure

•	Error Indication

•

Gb: This is the SGSN’s interface to the base station system (BSS) in a 2G radio access network (RAN). It connects the SGSN via UDP/IP (via an Ethernet interface) or Frame Relay (via a Channelized SDH or SONET interface). Gb-IP is the preferred interface as it improves control plane scaling as well as facilitates the deployment of SGSN Pools.

Some of the procedures supported across this interface are:

•	BSS GSM at 900/1800/1900 MHz

•

BSS Edge

•	Frame Relay congestion handling

•	Traffic management per Frame Relay VC

•	NS load sharing

•	NS control procedures

•	BVC management procedures

•	Paging for circuit-switched services

•	Suspend/Resume

•	Flow control

•	Unacknowledged mode

•	Acknowledged mode

•	Gn/Gp: The Gn/Gp interfaces, comprised of GTP/UDP/IP-based protocol stacks, connect the SGSNs and GGSNs to other SGSNs and GGSNs within the same PLMN (the Gn) or to GGSNs in other PLMNs (the Gp).

This implementation supports:

•	GTPv0 and GTPv1, with the capability to auto-negotiate the version to be used with any particular peer

•	GTP-C (control plane) and GTP-U (user plane)

•	Transport over ATM/STM-1Optical, Fast Ethernet, and Ethernet 1000 line cards/QGLCs)

•	One or more Gn/Gp interfaces configured per system context

As well, the SGSN can support the following IEs from later version standards:

•

IMEI-SV

•

RAT TYPE

•	User Location Information

•	Ge: This is the interface between the SGSN and the SCP that supports the CAMEL service. It supports both SS7 and SIGTRAN and uses the CAP protocol.

•	Gr: This is the interface to the HLR. It supports SIGTRAN (M3UA/SCTP/IP) over Ethernet.

Some of the procedures supported by the SGSN on this interface are:

•	Send Authentication Info

•	Update Location

•	Insert Subscriber Data

•	Delete Subscriber Data

•	Cancel Location

•

Purge

•

Reset

•	Ready for SM Notification

•	SIGTRAN based interfaces M3UA/SCTP

•	Peer connectivity can be through an intermediate SGP or directly depending on whether the peer (HLR, EIR, SMSC, GMLC) is SIGTRAN enabled or not

•	SCTP Multi-Homing supported to facilitate network resiliency

•	M3UA operates in IPSP client/server and single/double-ended modes

•	Multiple load shared M3UA instances for high-performance and redundancy

•	Works over Ethernet (IPoA) interface

•

Gs: This is the interface used by the SGSN to communicate with the visitor location register (VLR) or mobile switching center (MSC) to support circuit switching (CS) paging initiated by the MSC. This interface uses Signaling Connection Control Part (SCCP) connectionless service and BSSAP+ application protocols.

•	Gd: This is the interface between the SGSN and the SMS Gateway (SMS-GMSC / SMS-IWMSC) for both 2G and 3G technologies through multiple interface mediums. Implementation of the Gd interface requires purchase of an additional license.

•	Gf: Interface is used by the SGSN to communicate with the equipment identity register (EIR) which keeps a listing of UE (specifically mobile phones) being monitored. The SGSN’s Gf interface implementation supports functions such as:

•	International Mobile Equipment Identifier-Software Version (IMEI-SV) retrieval

•	IMEI-SV status confirmation

SGSN Core Functionality

The 2.5G and 3G SGSNs core functionality is comprised of SGSN:

•	All-IP Network (AIPN)

•	SS7 Support

•	PDP Context Support

•	Mobility Management

•	Location Management

•	Session Management

•

Charging

All-IP Network (AIPN)

AIPN provides enhanced performance, future-proof scaling and reduction of inter-connectivity complexity.

In accordance with 3GPP, the SGSN provides IP-based transport on all RAN and core network interfaces, in addition to the standard IP-based interfaces (Ga, Gn, Gp, Iu-Data). The all-IP functionality is key to facilitating Iu and Gb Flex (SGSN pooling) functionality as well as evolution to the next generation technology requirements.

SS7 Support

The ASR 5000 SGSN implements SS7 functionality to communicate with the various SS7 network elements, such as HLRs and VLRs.

The SGSN employs standard SS7 addressing (point codes) and global title translation. SS7 feature support includes:

•	Transport layer support includes:

•	Broadband SS7 (MTP3B/SSCF/SSCOP/AAL5)

•	Narrowband SS7 (high speed and low speed)

•	SIGTRAN (M3UA/SCTP/IP)

•	SS7 variants supported:

•	ITU-T (International Telecommunication Union - Telecommunications - Europe)

•	ANSI (American National Standards Institute - U.S.)

•	B-ICI (B-ISDN Inter-Carrier Interface)

•

China

•	TTC (Telecommunication Technology Committee - Japan)

•	NTT (Japan)

•	SS7 protocol stack components supported:

•

MTP2

•

MTP3

•	SCCP with BSSAP+ and RANAP

•

ISUP

•	TCAP and MAP

PDP Context Support

Support for subscriber primary and secondary Packet Data Protocol (PDP) contexts in compliance with 3GPP standards ensure complete end-to-end GPRS connectivity.

The SGSN supports a total of 11 PDP contexts per subscriber. Of the 11 PDP context, all can be primaries, or 1 primary and 10 secondaries or any combination of primary and secondary. Note that there must be at least one primary PDP context in order for secondaries to establish.

PDP context processing supports the following types and functions:

•	Types: IPv4, IPv6, and/or PPP

•	GTPP accounting support

•	PDP context timers

•	Quality of Service (QoS)

Mobility Management

The SGSN supports mobility management (MM) in compliance with applicable 3GPP standards and procedures to deliver the full range of services to the mobile device. Some of the procedures are highlighted below:

GPRS Attach

The SGSN is designed to accommodate a very high rate of simultaneous attaches. The actual attach rate depends on the latencies introduced by the network and scaling of peers. In order to optimize the entire signaling chain, the SGSN eliminates or minimizes bottlenecks caused by large scale control signaling. For this purpose, the SGSN implements features such as an in-memory data-VLR and SuperCharger. Both IMSI and P-TMSI based attaches are supported.

The SGSN provides the following mechanisms to control MN attaches:

•

Attached Idle Timeout - When enabled, if an MN has not attempted to setup a PDP context since attaching, this timer forces the MN to detach with a cause indicating that the MN need not re-attach. This timer is particularly useful for reducing the number of attached subscribers, especially those that automatically attach at power-on.

•	Detach Prohibit - When enabled, this mechanism disables the Attached Idle Timeout functionality for selected MNs which aggressively re-attach when detached by the network.

•	Prohibit Reattach Timer - When enabled, this timer mechanism prevents MNs, that were detached due to inactivity, from re-attaching for a configured period of time. Such MNs are remembered by the in-memory data-VLR until the record needs to be purged.

•

Attach Rate Throttle - It is unlikely that the SGSN would become a bottleneck because of the SGSN’s high signaling rates. However, other nodes in the network may not scale commensurately. To provide network overload protection, the SGSN provides a mechanism to control the number of attaches occurring through it on a per second basis.

Beside configuring the rate, it is possible to configure the action to be taken when the overload limit is reached. See the network-overload-protection command in the “Global Configuration Mode” chapter in the Cisco ASR 5000 Series Command Line Interface Reference. Note, this is a soft control and the actual attach rate may not match exactly the configured value depending on the load conditions.

GPRS Detach

The SGSN is designed to accommodate a very high rate of simultaneous detaches. However, the actual detach rate is dependent on the latencies introduced by the network and scaling of peers. A GPRS detach results in the deactivation of all established PDP contexts.

There are a variety of detaches defined in the standards and the SGSN supports the following detaches:

•	MN Initiated Detach - The MN requests to be detached.

•	SGSN Initiated Detach - The SGSN requests the MN to detach due to expiry of a timer or due to administrative action.

•	HLR Initiated Detach - The detach initiated by the receipt of a cancel location from the HLR.

Mass detaches triggered by administrative commands are paced in order to avoid flooding the network and peer nodes with control traffic.

Paging

CS-Paging is initiated by a peer node - such as the MSC - when there is data to be sent to an idle or unavailable UE. CS-paging requires the Gs interface. This type of paging is intended to trigger a service request from the UE. If necessary, the SGSN can use PS-Paging to notify the UE to switch channels. Once the UE reaches the connected state, the data is forwarded to it.

Paging frequency can be controlled by configuring a paging-timer.

Service Request

The Service Request procedure is used by the MN in the PMM Idle state to establish a secure connection to the SGSN as well as request resource reservation for active contexts.

The SGSN allows configuration of the following restrictions:

•	Prohibition of services

•	Enforce identity check

•	PLMN restriction

•	Roaming restrictions

Authentication

The SGSN authenticates the subscriber via the authentication procedure. This procedure is invoked on attaches, PDP activations, inter-SGSN routing Area Updates (RAUs), and optionally on configurable periodic RAUs. The procedure requires the SGSN to retrieve authentication quintets/triplets from the HLR (AuC) and issuing an authentication and ciphering request to the MN. The SGSN implements an in-memory data-VLR functionality to pre-fetch and store authentication vectors from the HLR. This decreases latency of the control procedures.

Additional configuration at the SGSN allows for the following:

•	Enforcing ciphering

•	Retrieval of the IMEI-SV

P-TMSI Reallocation

The SGSN supports standard Packet-Temporary Mobile Identity (P-TMSI) Reallocation procedures to provide identity confidentiality for the subscriber.

The SGSN can be configured to allow or prohibit P-TMSI reallocation on the following events:

•	Routing Area Updates

•

Attaches

•

Detaches

•	Service Requests

The SGSN reallocates P-TMSI only when necessary.

P-TMSI Signature Reallocation

The SGSN supports operator definition of frequency and interval for Packet Temporary Mobile Subscriber Identity (P-TMSI) signature reallocation for all types of routing area update (RAU) events.

Identity Request

This procedure is used to retrieve IMSI and IMEI-SV from the MN. The SGSN executes this procedure only when the MN does not provide the IMSI and the MM context for the subscriber is not present in the SGSN’s data-VLR.

Location Management

The SGSN’s 3GPP compliance for location management ensures efficient call handling for mobile users.

The SGSN supports routing area updates (RAU) for location management. The SGSN implements standards based support for:

•	Periodic RAUs

•	Intra-SGSN RAUs

•	Inter-SGSN RAUs.

The design of the SGSN allows for very high scalability of RAUs. In addition, the high capacity of the SGSN and Flex functionality provides a great opportunity to convert high impact Inter-SGSN RAUs to lower impact Intra-SGSN RAUs. The SGSN provides functionality to enforce the following RAU restrictions:

•	Prohibition of GPRS services

•	Enforce identity request

•	Enforce IMEI check

•	PLMN restriction

•	Roaming restrictions

The SGSN also provides functionality to optionally supply the following information to the MN:

•	P-TMSI Signature and Allocated P-TMSI

•	List of received N-PDU numbers for loss less relocation

•	Negotiated READY timer value

•	Equivalent PLMNs

•	PDP context status

•	Network features supported

Session Management

Session management ensures proper PDP context setup and handling.

For session management, the SGSN supports four 3GPP-compliant procedures for processing PDP contexts:

•	Activation

•	Modification

•	Deactivation

•	Preservation

PDP Context Activation

The PDP context activation procedure establishes a PDP context with the required QoS from the MN to the GGSN. These can be either primary or secondary contexts. The SGSN supports a minimum of 1 PDP primary context per attached subscriber, and up to a maximum of 11 PDP contexts per attached subscriber.

The PDP context types supported are:

•	PDP type IPv4

•	PDP type IPv6

•	PDP type PPP

Both dynamic and static addresses for the PDP contexts are supported.

The SGSN provides configuration to control the duration of active and inactive PDP contexts.

When activating a PDP context the SGSN can establish the GTP-U data plane from the RNC through the SGSN to the GGSN or directly between the RNC and the GGSN (one tunnel).

The SGSN is capable of interrogating the DNS infrastructure to resolve the specified APN to the appropriate GGSN. The SGSN also provides default and override configuration of QoS and APN.

PDP Context Modification

This procedure is used to update the MN and the GGSN. The SGSN is capable of initiating the context modification or negotiating a PDP context modification initiated by either the MN or the GGSN.

PDP Context Deactivation

This procedure is used to deactivate PDP contexts. The procedure can be initiated by the MN or the SGSN. The SGSN provides configurable timers to initiate PDP deactivation of idle contexts as well as active contexts.

PDP Context Preservation

The SGSN provides this functionality to facilitate efficient radio resource utilization. This functionality comes into play on the following triggers:

•	RAB (Radio Access Bearer) Release Request

This is issued by the RAN to request the release of RABs associated with specific PDP contexts. The SGSN responds with a RAB assignment request, waits for the RAB assignment response and marks the RAB as having been released. The retention of the PDP contexts is controlled by configuration at the SGSN. If the PDP contexts are retained the SGSN is capable of receiving downlink packets on them.

•	Iu Release Request

The RAN issues an Iu release request to release all RABs of an MN and the Iu connection. The retention of the PDP contexts is controlled by configuration at the SGSN. When PDP contexts are retained the SGSN is capable of receiving downlink packets on them.

When PDP contexts are preserved, the RABs can be restored on a service request from the MN without having to go through the PDP context establishment process again. The service request is issued by the MN either when it has some data to send or in response to a paging request, on downlink data, from the SGSN.

Charging

To provide efficient and accurate billing for calls and SMS passing through the SGSN, the system:

•	allows the configuration of multiple CGFs and GSSs and their relative priorities.

•	implements the standardized Ga interface,

•	fully supports the GPRS Tunneling Protocol Prime (GTPP) over UDP, and

•	supports the relevant charging information as defined in

•	3GPP TS 29.060 v7.9.0 (2008-09): Technical Specification; 3rd Generation Partnership Project; Technical Specification Group Core Network; General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface (Release 6)

•	3GPP TS 32.215 v5.9.0 (2005-06): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Charging management; Charging data description for the Packet Switched (PS) domain (Release 4)

•	3GPP TS.32.251 V6.10.0 (2007-06): 3rd Generation Partnership Project; Group Services and System Aspects; Telecommunication management; Charging management; Packet Switched (PS) domain charging (Release 6)

•	3GPP TS 32.298 V6.5.0 (2006-09): 3rd Generation Partnership Project; Technical Specification Group Service and System Aspects; Telecommunication management; Charging management; Charging Data Record (CDR) parameter description (Release 6)

The following provides outlines the types of CDRs supported by the SGSN. For full dictionary, CDR and field information, refer to the GTPP Accounting Overview, the SGSN and Mobility Management Charging Detail Record Field Reference Tables, and the S-CDR Field Descriptions chapters in the AAA and GTPP Interface Administartion and Reference

SGSN Call Detail Records (S-CDRs)

These charging records are generated for PDP contexts established by the SGSN. They contain attributes as defined in TS 32.251 v7.2.0.

Mobility Call Detail Records (M-CDRs)

These charging records are generated by the SGSN’s mobility management (MM) component and correspond to the mobility states. They contain attributes as defined in 3GPP TS 32.251 v7.2.0.

Short Message Service CDRs

SGSN supports following CDRs for SMS related charging:

•	SMS-Mobile Originated CDRs (SMS-MO-CDRs)

•	SMS Mobile Terminated CDRs (SMS-MT-CDRs)

These charging records are generated by the SGSN’s Short Message Service component. They contain attributes as defined in 3GPP TS 32.215 v5.9.0.

Features and Functionality

It is impossible to list all of the features supported by the ASR 5000 2.5G and/or 3G SGSN.

Those features listed below are only a few of the features that enable the operator to control the SGSN and their network. All of these features are either proprietary or comply with relevant 3GPP specifications.

Some of the proprietary features may require a separate license. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.

The following is an alphabetical list of the features described in this overview:

•	APN Aliasing

•	APN Resolution with SCHAR or RNC-ID

•	Automatic Protection Switching (APS)

•	Authentications and Reallocations -- Selective

•	Avoiding PDP Context Deactivations

•	Bulk Statistics Support

•	CAMEL Service Phase 3, Ge Interface

•	Direct Tunnel

•	DSCP Template for Control and Data Packets - Gb over IP

•	Dual PDP Addresses for Gn/Gp

•	Equivalent PLMN

•	First Vector Configurable Start for MS Authentication

•	GMM-SM Event Logging

•	GnGp Delay Monitoring

•	GTP-C Path Failure Detection and Management

•	Handling Multiple MS Attaches All with the Same Random TLLI

•	Intra- or Inter-SGSN Serving Radio Network Subsystem (SRNS) Relocation (3G only)

•	Iu Redundancy (ECMP over ATM)

•	Lawful Intercept

•	Link Aggregation - Horizontal

•

Local DNS

•	Local Mapping of MBR

•	Local QoS Capping

•	Management System Overview

•	Multiple PLMN Support

•	Network Sharing

•	NPU FastPath

•	NRPCA - 3G

•	Operator Policy

•	Overcharging Protection

•	QoS Traffic Policing per Subscriber

•	Reordering of SNDCP N-PDU Segments

•	Session Recovery

•	SGSN Pooling and Iu-Flex Gb-Flex

•	Short Message Service (SMS over Gd)

•	SMS Authentication Repetition Rate

•	SMSC Address Denial

•	Threshold Crossing Alerts (TCA) Support

•	Tracking Usage of GEA Encryption Algorithms

•	VLR Pooling via the Gs Interface

APN Aliasing

In many situations, the APN provided in the Activation Request is unacceptable – perhaps it does not match with any of the subscribed APNs or it is misspelled – and would result in the SGSN rejecting the Activation Request. The APN Aliasing feature enables the operator to override an incoming APN – specified by a subscriber or provided during the APN selection procedure (TS 23.060) – or replace a missing APN with an operator-preferred APN.

The APN Aliasing feature provides a set of override functions: Default APN, Blank APN, APN Remapping, and Wildcard APN to facilitate such actions as:

•	overriding an HFL-mismatched APN with a default APN.

•	overriding a missing APN (blank APN) with a default or preferred APN.

•	overriding an APN on the basis of charging characteristics.

•	overriding an APN by replacing part or all of the network or operator identifier with information defined by the operator, for example, MNC123.MCC456.GPRS could be replaced by MNC222.MCC333.GPRS.

•	overriding an APN for specific subscribers (based on IMSI) or for specific devices (based on IMEI).

Default APN

Operators can configure a “default APN” for subscribers not provisioned in the HLR. The default APN feature will be used in error situations when the SGSN cannot select a valid APN via the normal APN selection process. Within an APN remap table, a default APN can be configured for the SGSN to:

•	override a requested APN when the HLR does not have the requested APN in the subscription profile.

•	provide a viable APN if APN selection fails because there was no “requested APN” and wildcard subscription was not an option.

In either of these instances, the SGSN can provide the default APN as an alternate behavior to ensure that PDP context activation is successful.

Recently, the SGSN’s default APN functionality was enhanced so that if a required subscription APN is not present in the subscriber profile, then the SGSN will now continue the activation with another configured 'dummy' APN. The call will be redirected, via the GGSN, to a webpage informing the user of the error and prompting to subscribe for services.

Refer to the APN Remap Table Configuration Mode in the Cisco ASR 5000 Series Command Line Interface Reference for the command to configure this feature.

APN Resolution with SCHAR or RNC-ID

It is now possible to append charging characteristic information to the DNS string. The SGSN includes the profile index value portion of the CC as binary/decimal/hexadecimal digits (type based on the configuration) after the APN network identification. The charging characteristic value is taken from the subscription record selected for the subscriber during APN selection. This enables the SGSN to select a GGSN based on the charging characteristics information.

After appending the charging characteristic the DNS string will take the following form: <apn_network_id>.<profile_index>.<apn_operator_id >. The profile index in the following example has a value 10: quicknet.com.uk.1010.mnc234.mcc027.gprs.

If the RNC_ID information is configured to be a part of the APN name, and if inclusion of the profile index of the charging characteristics information is enabled before the DNS query is sent, then the profile index is included after the included RNC_ID and the DNS APN name will appear in the following form: <apn_network_id>.<rnc_id>.<profile_index>.<apn_operator_id>. In the following example, the DNS query for a subscriber using RNC 0321 with the profile index of value 8 would appear as: quicknet.com.uk.0321.1000.mnc234.mcc027.gprs.

Automatic Protection Switching (APS)

Automatic protection switching (APS is now available on an inter-card basis for SONET configured CLC2 (Frame Relay) and OLC2 (ATM) optical line cards. Multiple switching protection (MSP) version of is also available for SDH configured for the CLC2 and OLC2 (ATM) line cards.

APS/MSP offers superior redundancy for SONET/SDH equipment and supports recovery from card failures and fiber cuts. APS allows an operator to configure a pair of SONET/SDH lines for line redundancy. In the event of a line problem, the active line switches automatically to the standby line within 60 milliseconds (10 millisecond initiation and 50 millisecond switchover).

At this time, the ASR 5000 APS/MSP supports the following parameters:

•	1+1 - Each redundant line pair consists of a working line and a protection line.

•	uni-directional - Protection on one end of the connection.

•	non-revertive - Upon restoration of service, this parameter prevents the network from automatically reverting to the original working line.

The protection mechanism used for the APS/MSP uses a linear 1+1 architecture, as described in the ITU-T G.841 standard and the Bellcore publication GR-253-CORE, SONET Transport Systems; Common Generic Criteria, Section 5.3. The connection is unidirectional.

With APS/MSP 1+1, each redundant line pair consists of a working line and a protection line. Once a signal fail condition or a signal degrade condition is detected, the hardware switches from the working line to the protection line.

With the non-revertive option, if a signal fail condition is detected, the hardware switches to the protection line and does not automatically revert back to the working line.

Since traffic is carried simultaneously by the working and protection lines, the receiver that terminates the APS/MSP 1+1 must select cells from either line and continue to forward one consistent traffic stream. The receiving ends can switch from working to protection line without coordinating at the transmit end since both lines transmit the same information.

SONET APS 1+1

Refer to the section on Configuring APS/MSP Redundancy in the SGSN Service Configuration Procedures chapter for configuration details.

Authentications and Reallocations -- Selective

Subscriber event authentication, P-TMSI reallocation, and P-TMSI signature reallocation are now selective rather than enabled by default.

The operator can enable and configure them to occur according to network requirements:

•	every instance or every nth instance;

•	on the basis of UMTS, GPRS or both;

•	on the basis of elapsed time intervals between events.

There are situations in which authentication will be performed unconditionally:

•	IMSI Attach – all IMSI attaches will be authenticated

•	When the subscriber has not been authenticated before and the SGSN does not have a vector

•	When there is a P-TMSI signature mismatch

•	When there is a CKSN mismatch

There are situation in which P-TMSI will be reallocated unconditionally:

•	Inter SGSN Attach/RAU

•	Inter-RAT Attach/RAU in 2G

•	IMSI Attach

Avoiding PDP Context Deactivations

The SGSN can be configured to avoid increased network traffic resulting from bursts of service deactivations/activations resulting from erroneous restart counter change values in received messages (Create PDP Context Response or Update PDP Context Response or Update PDP Context Request). Be default, the SGSN has the responsibility to verify possible GTP-C path failure by issuing an Echo Request/Echo Response to the GGSN. Path failure will only be confirmed if the Echo Response contains a new restart counter value. Only after this confirmation of the path failure does the SGSN begin deactivation of PDP contexts.

Bulk Statistics Support

System support for bulk statistics allows operators to choose which statistics to view and to configure the format in which the statistics are presented. This simplifies the post-processing of statistical data since it can be formatted to be parsed by external, back-end processors.

When used in conjunction with the Web Element Manager, the data can be parsed, archived, and graphed.

The system can be configured to collect bulk statistics (performance data) and send them to a collection server (called a receiver). Bulk statistics are statistics that are collected in a group. The individual statistics are grouped by schema. The following is the list of schemas supported for use by the SGSN:

•	System: Provides system-level statistics

•	Card: Provides card-level statistics

•	Port: Provides port-level statistics

•	DLCI-Util: Provides statistics specific to DLCIs utilization for CLC-type line cards

•	GPRS: Provides statistics for LLC, BSSGP, SNDCP, and NS layers

•	SCCP: Provides SCCP network layer statistics

•	SGTP: Provides SGSN-specific GPRS Tunneling Protocol (GTP) staistics

•	SGSN: Provides statistics for: mobility management (MM) and session management (SM) procedures; as well, MAP, TCAP, and SMS counters are captured in this schema. SGSN Schema statistic availablility is per service (one of: SGSN, GPRS, MAP) and per routing area (RA)

•	SS7Link: Provides SS7 link and linkset statistics

•	SS7RD: Provides statistics specific to the proprietary SS7 routing domains

The system supports the configuration of up to 4 sets (primary/secondary) of receivers. Each set can be configured with to collect specific sets of statistics from the various schemas. Statistics can be pulled manually from the chassis or sent at configured intervals. The bulk statistics are stored on the receiver(s) in files.

The format of the bulk statistic data files can be configured by the user. Users can specify the format of the file name, file headers, and/or footers to include information such as the date, chassis host name, chassis uptime, the IP address of the system generating the statistics (available for only for headers and footers), and/or the time that the file was generated.

When the Web Element Manager is used as the receiver, it is capable of further processing the statistics data through XML parsing, archiving, and graphing.

The Bulk Statistics Server component of the Web Element Manager parses collected statistics and stores the information in the PostgreSQL database. If XML file generation and transfer is required, this element generates the XML output and can send it to a Northbound NMS or an alternate bulk statistics server for further processing.

Additionally, if archiving of the collected statistics is desired, the Bulk Statistics server writes the files to an alternative directory on the server. A specific directory can be configured by the administrative user or the default directory can be used. Regardless, the directory can be on a local file system or on an NFS-mounted file system on the Web Element Manager server.

CAMEL Service Phase 3, Ge Interface

The ASR 5000 SGSN provides PDP session support as defined by Customized Applications for Mobile network Enhanced Logic (CAMEL) phase 3.

CAMEL Service

CAMEL service enables operators of 2.5G/3G networks to provide operator-specific services (such as prepaid GPRS service and prepaid SMS service) to subscribers, even when the subscribers are roaming outside their HPLMN.

CAMEL Support

ASR 5000 SGSN support for CAMEL phase 3 services expands with each SGSN application release. Current support enables operators of 2.5G/3G networks to provide operator-specific services (such as prepaid GPRS service and prepaid SMS service) to subscribers, even when the subscribers are roaming outside their HPLMN.

For this release the SGSN has expanded its support for CAMEL Scenario 1 adding:

•	Implementation of Scenario1 triggers (TDP-Attach, TDP-Attach-ChangeofPosition)

•	Implementation of Scenario1 Dynamic triggers (DP-Detach, DP-ChangeofPosition)

•	Expanded conformance to 3GPP spec 23.078 (Release 4)

The ASR 5000 SGSN supports the following GPRS-related functionality in CAMEL phase 3:

•	Control of GPRS PDP contexts

Functional support for CAMEL interaction includes:

•	PDP Context procedures per 3GPP TS 29.002

•	GPRS TDP (trigger detection point) functions

•	Default handling codes, if no response received from SCP

•	GPRS EDP (event detection points) associated with SCP

•	Charging Procedures: Handle Apply Charging GPRS & Handle Apply Charging Report GPRS

•	“GPRS Dialogue scenario 2" for CAMEL control with SCP

•	CAMEL-related data items in an S-CDR:

•	SCF Address

•	Service Key

•	Default Transaction Handling

•	Level of CAMEL service (phase 3)

•	Session Recovery for all calls have an ESTABLISHED CAMEL association.

Ge Interface

The ASR 5000 implementation of CAMEL uses standard CAP protocol over a Ge interface between the SGSN and the SCP. This interface can be deployed over SS7 or SIGTAN.

The SGSN's Ge support includes use of the gprsSSF CAMEL component with the SGSN and the gsmSCF component with the SCP.

CAMEL Configuration

To provide the CAMEL interface on the SGSN, a new service configuration mode, called “CAMEL Service”, has been introduced on the SGSN.

1.	An SCCP Network configuration must be created or exist already.

2.	A CAMEL Service instance must be created.

3.	The CAMEL Service instance must be associated with either the SGSN Service configuration or the GPRS Service configuration in order to enable use of the CAMEL interface.

4.	The CAMEL Service must be associated with the SCCP Network configuration.

Until a CAMEL Service is properly configured, the SGSN will not process any TDP for pdp-context or mo-sms.

For configuration details, refer to the Cisco ASR 5000 Series Serving GPRS Support Node Administration Guide and the Cisco ASR 5000 Series Command Line Interface Reference.

Direct Tunnel

In accordance with standards, one tunnel functionality enables the SGSN to establish a direct tunnel at the user plane level - a GTP-U tunnel, directly between the RAN and the GGSN. Feature details and configuration procedures are provided in the Direct Tunnel chapter in this guide.

DSCP Template for Control and Data Packets - Gb over IP

One or more reusable templates, setting DSCP parameter configuration for downlink control packets and data packets, can be created and associated with one or more GPRS Service configurations.

Dual PDP Addresses for GnGp

In accordance with 3GPP Release 9.0 specifications, it is now possible to configure SGSN support for dual PDP type addressing (IPv4v6) for PDP context association with one IPv4 address and one IPv6 address/prefix when requested by the MS/UE.

Equivalent PLMN

This feature is useful when an operator deploys both GPRS and UMTS access in the same radio area and each radio system broadcasts different PLMN codes. It is also useful when operators have different PLMN codes in different geographical areas, and the operators’ networks in the various geographical areas need to be treated as a single HPLMN.

This feature allows the operator to consider multiple PLMN codes for a single subscriber belonging to a single home PLMN (HPLMN). This feature also allows operators to share infrastructure and it enables a UE with a subscription with one operator to access the network of another operator.

First Vector Configurable Start for MS Authentication

Previously, the SGSN would begin authentication towards the MS only after the SGSN received all requested vectors. This could result in a radio network traffic problem when the end devices timed out and needed to resend attach requests.

Now, the SGSN can be configured to start MS authentication as soon as it receives the first vector from the AuC/HLR while the SAI continues in parallel. After an initial attach request, some end devices restart themselves after waiting for the PDP to be established. In such cases, the SGSN restarts and a large number of end devices repeat their attempts to attach. The attach requests flood the radio network, and if the devices timeout before the PDP is established then they continue to retry, thus even more traffic is generated. This feature reduces the time needed to retrieve vectors over the GR interface to avoid the high traffic levels during PDP establishment and to facilitate increased attach rates.

GMM-SM Event Logging

To facilitate troubleshooting, the SGSN will capture procedure-level information per 2G or 3G subscriber (IMSI-based) in CSV formatted event data records (EDRs) that are stored on an external server.

This feature logs the following events:

•

Attaches

•	Activation of PDP Context

•

RAU

•

ISRAU

•	Deactivation of PDP Context

•

Detaches

•	Authentications

•	PDP Modifications

The new SGSN event logging feature is enabled/disabled per service with via the CLI commands. For more information on this feature, refer to the chapter GMM/SM Event Logging in this guide.

Gn/Gp Delay Monitoring

The SGSN measures the control plane packet delay for GTP-C signaling messages on the SGSN’s Gn/Gp interface towards the GGSN.

If the delay crosses a configurable threshold, an alarm will be generated to prompt the operator.

A delay trap is generated when the GGSN response to an ECHO message request is delayed more than a configured amount of time and for a configured number of consecutive responses. When this occurs, the GGSN will be flagged as experiencing delay.

A clear delay trap is generated when successive ECHO Response (number of successive responses to detect a delay clearance is configurable), are received from a GGSN previously flagged as experiencing delay.

This functionality can assist with network maintenance, troubleshooting, and early fault discovery.

GTP-C Path Failure Detection and Management

The SGSN now provides the ability to manage GTP-C path failures detected as a result of spurious restart counter change messages received from the GGSN.

Previous Behavior: The old default behavior was to have the Session Manager (SessMgr) detect GTP-C path failure based upon receiving restart counter changes in messages (Create PDP Context Response or Update PDP Context Response or Update PDP Context Request) from the GGSN and immediately inform the SGTPC Manager (SGTPCMgr) to pass the path failure detection to all other SessMgrs so that PDP deactivation would begin.

New Behavior: The new default behavior has the SessMgr inform the SGTPCMgr of the changed restart counter value. The SGTPCMgr now has the responsibility to verify a possible GTP-C path failure by issuing an Echo Request/Echo Response to the GGSN. Path failure will only be confirmed if the Echo Response contains a new restart counter value. Only after this confirmation of the path failure does the SGTPCMgr inform all SessMgrs so that deactivation of PDP contexts begins.

Handling Multiple MS Attaches All with the Same Random TLLI

Some machine-to-machine (M2M) devices from the same manufacturer will all attempt PS Attaches using the same fixed random Temporary Logical Link Identifier (TLLI).

The SGSN cannot distinguish between multiple M2M devices trying to attach simultaneously using the same random TLLI and routing area ID (RAI). As a result, during the attach process of an M2M device, if a second device tries to attach with the same random TLLI, the SGSN interpretes that as an indication that the original subscriber moved during the Attach process and the SGSN starts communicating with the second device and drops the first device.

The SGSN can be configured to allow only one subscriber at a time to attach using a fixed random TLLI. While an Attach procedure with a fixed random TLLI is ongoing (that is, until a new P-TMSI is accepted by the MS), all other attaches sent to the SGSN with the same random TLLI using a different IMSI will be dropped by the SGSN’s Linkmgr.

To limit the wait-time functionality to only the fixed random TLLI subscribers, the TLLI list can be configured to control which subscribers will be provided this functionality.

HSPA Fallback

Besides enabling configurable support for either 3GPP Release 6 (HSPA) and 3GPP Release 7 (HSPA+) to match whatever the RNCs support, this feature enables configurable control of data rates on a per RNC basis. This means that operators can allow subscribers to roam in and out of coverages areas with different QoS levels.

The SGSN can now limit data rates (via QoS) on a per-RNC basis. Some RNCs support HSPA rates (up to 16 Mbps in the downlink and 8 Mbps in the uplink) and cannot support higher data rates - such as those enabled by HSPA+ (theoretically, up to 256 Mbps both downlink and uplink). Being able to specify the QoS individually for each RNC makes it possible for operators to allow their subscribers to move in-and-out of coverage areas with different QoS levels, such as those based on 3GPP Release 6 (HSPA) and 3GPP Release 7 (HSPA+).

For example, when a PDP context established from an RNC with 21 Mbps is handed off to an RNC supporting only 16 Mbps, the end-to-end QoS will be re-negotiated to 16 Mbps. Note that an MS/UE may choose to drop the PDP context during the QoS renegotiation to a lower value.

This data rate management per RNC functionality is enabled, in the radio network controller (RNC) configuration mode, by specifying the type of 3GPP release specific compliance, either release 7 for HSPA+ rates or pre-release 7 for HSPA rates. For configuration details, refer to the RNC Configuration Mode chapter in the Cisco ASR 5000 Series Command Line Interface Reference.

Intra- or Inter-SGSN Serving Radio Network Subsystem (SRNS) Relocation (3G only)

Implemented according to 3GPP standard, the SGSN supports both inter- and intra-SGSN RNS relocation (SRNS) to enable handover of an MS from one RNC to another RNC.

The relocation feature is triggered by subscribers (MS/UE) moving from one RNS to another. If the originating RNS and destination RNS are connected to the same SGSN but are in different routing areas, the behavior triggers an intra-SGSN Routing Area Update (RAU). If the RNS are connected to different SGSNs, the relocation is followed by an inter-SGSN RAU. This feature is configured through the Call-Control Profile Configuration Mode which is part of the feature set.

Iu Redundancy (ECMP over ATM)

Iu Redundancy is the ASR 5000's implementation of equal-cost multi-path routing (ECMP) over ATM.

ECMP over ATM

Iu Redundancy is based on the standard ECMP multi-path principle of providing multiple next-hop-routes of equal cost to a single destination for packet transmission. ECMP works with most routing protocols and can provide increased bandwidth when traffic load-balancing is implemented over multiple paths.

ECMP over ATM will create an ATM ECMP group when multiple routes with different destination ATM interfaces are defined for the same destination IP address. When transmitting a packet with ECMP, the NPU performs a hash on the packet header being transmitted and uses the result of the hash to index into a table of next hops. The NPU looks up the ARP index in the ARP table (the ARP table contains the next-hop and egress interfaces) to determine the next-hop and interface for sending packets.

Lawful Intercept

The Cisco Lawful Intercept feature is supported on the SGSN. Lawful Intercept is a license-enabled, standards-based feature that provides telecommunications service providers with a mechanism to assist law enforcement agencies in monitoring suspicious individuals for potential illegal activity. For additional information and documentation on the Lawful Intercept feature, contact your Cisco account representative.

Link Aggregation - Horizontal

The SGSN supports enhanced link aggregation (LAG) within ports on different XGLCs. Ports can be from multiple XGLCs. LAG works by exchanging control packets (Link Aggregation Control Marker Protocol) over configured physical ports with peers to reach agreement on an aggregation of links. LAG sends and receives the control packets directly on physical ports attached to different XGLCs. The link aggregation feature provides higher aggregated bandwidth, auto-negotiation, and recovery when a member port link goes down.

Local DNS

Previously, the SGSN supported GGSN selection for an APN only through operator policy, and supported a single pool of up to 16 GGSN addresses which were selected in round robin fashion.

The SGSN now supports configuration of multiple pools of GGSNs; a primary pool and a secondary. As part of DNS resolution, the operator can use operator policies to prioritize local GGSNs versus remote ones. This function is built upon existing load balancing algorithms in which weight and priority are configured per GGSN, with the primary GGSN pool used first and the secondary used if no primary GGSNs are available.

The SGSN first selects a primary pool and then GGSNs within that primary pool; employing a round robin mechanism for selection. If none of the GGSNs in a pool are available for activation, then the SGSN proceeds with activation selecting a GGSN from a secondary pool on the basis of assigned weight. A GGSN is considered unavailable when it does not respond to GTP Requests after a configurable number of retries over a configurable time period. Path failure is detected via GTP-echo.

Local Mapping of MBR

The SGSN provides the ability to map a maximum bit rate (MBR) value (provided by the HLR) to an HSPA MBR value.

The mapped value is selected based on the matching MBR value obtained from the HLR subscription. QoS negotiation then occurs based on the converted value.

This feature is available within the operator policy framework. MBR mapping is configured via new keywords added to the qos class command in the APN Profile configuration mode. A maximum of four values can be mapped per QoS per APN.

Important: To enable this feature the qos prefer-as-cap, also a command in the APN Profile configuration mode, must be set to either both-hlr-and-local or to hlr subscription.

Local QoS Capping

The operator can configure a cap or limit for the QoS bit rate.

The SGSN can now be configured to cap the QoS bit rate parameter when the subscribed QoS provided by the HLR is lower than the locally configured value.

Depending upon the keywords included in the command, the SGSN can:

•	take the QoS parameter configuration from the HLR configuration.

•	take the QoS parameter configuration from the local settings for use in the APN profile.

•	during session establishment, apply the lower of either the HLR subscription or the locally configured values.

Refer to the APN Profile Configuration Mode chapter of the Cisco ASR 5000 Series Command Line Interface Reference for the qos command.

Management System Overview

The system's management capabilities are designed around the Telecommunications Management Network (TMN) model for management - focusing on providing superior quality network element (NE) and element management system (Web Element Manager) functions. The system provides element management applications that can easily be integrated, using standards-based protocols (CORBA and SNMPv1, v2), into higher-level management systems - giving wireless operators the ability to integrate the system into their overall network, service, and business management systems. In addition, all management is performed out-of-band for security and to maintain system performance.

The Operation and Maintenance module of the system offers comprehensive management capabilities to the operators and enables them to operate the system more efficiently. There are multiple ways to manage the system either locally or remotely using its out-of-band management interfaces.

These include:

•	Using the command line interface (CLI)

•	Remote login using Telnet, and Secure Shell (SSH) access to CLI through SPIO card's Ethernet management interfaces

•	Local login through the Console port on SPIO card using an RS-232 serial connection

•	Using the Web Element Manager (WEM) application (requires a separate license)

•	Supports communications through 10 Base-T, 100 Base-TX, 1000 Base-TX, or 1000

•	Base-SX (optical gigabit Ethernet) Ethernet management interfaces on the SPIO

•	Client-Server model supports any browser (i.e. Microsoft Internet Explorer v5.0 and above or Netscape v4.7 or above, and others)

•	Supports Common Object Request Broker Architecture (CORBA) protocol and Simple Network Management Protocol version 1 (SNMPv1) for fault management

•	Provides complete Fault, Configuration, Accounting, Performance, and Security (FCAPS) capabilities

•	Can be easily integrated with higher-level network, service, and business layer applications using the Object Management Group's (OMG’s) Interface Definition Language (IDL)

The following figure demonstrates these various element management options and how they can be utilized within the wireless carrier network.

Element Management Methods

Important: SGSN management functionality is enabled by default for console-based access. For GUI-based management support, refer Web Element Management System. For more information on command line interface based management, refer to the Command Line Interface Reference.

Multiple PLMN Support

With this feature, the 2.5G and 3G SGSNs now support more than one PLMN ID per SGSN. Multiple PLMN support facilitates MS handover from one PLMN to another PLMN.

Multiple PLMN support also means an operator can 'hire out' their infrastructure to other operators who may wish to use their own PLMN IDs. As well, multiple PLMN support enables an operator to assign more than one PLMN ID to a cell-site or an operator can assign each cell-site a single PLMN ID in a multi-cell network (typically, there are no more than 3 or 4 PLMN IDs in a single network).

This feature is enabled by configuring, within a single context, multiple instances of either an IuPS service for a single 3G SGSN service or multiple GPRS services for a 2.G SGSN. Each IuPS service or GPRS service is configured with a unique PLMN ID. Each of the SGSN and/or GPRS services must use the same MAP, SGTPU and GS services so these only need to be defined one-time per context.

Network Sharing

In accordance with 3GPP TS 23.251, the SGSN provides an operator the ability to share the RAN and/or the core network with other operators. Depending upon the resources to be shared, there are 2 network sharing modes of operation: the Gateway Core Network (GWCN) and the Multi-Operator Core Network (MOCN).

Benefits of Network Sharing

Network sharing provides operators with a range of logistical and operational benefits:

•	Enables two or more network operators to share expensive common network infrastructure.

•	A single operator with multiple MCC-MNC Ids can utilize a single physical access infrastructure and provide a single HPLMN view to the UEs.

•	Facilitates implementation of MVNOs.

GWCN Configuration

With a gateway core network configuration, the complete radio access network and part of the core network are shared (for example, MSC/SGSN) among different operators, while each operator maintains its own separate network nodes (for example, GGSN/HLR).

GWCN-type Network Sharing

With the GWCN configuration, the SGSN supports two scenarios:

•	GWCN with non-supporting UE

•	GWCN with supporting UE

MOCN Configuration

In the multi-operator core network configuration, the complete radio network is shared among different operators, while each operators maintains its own separate core network.

MOCN-type Network Sharing

With the MOCN configuration, the SGSN supports the following scenarios:

•	MOCN with non-supporting UE

•	MOCN with supporting UE

Implementation

To facilitate network sharing, the SGSN implements the following key features:

•	Multiple virtual SGSN services in a single physical node.

•	Sharing operators can implement independent policies, such as roaming agreements.

•	Equivalent PLMN configuration.

•	RNC identity configuration allows RNC-ID + MCC-MNC instead of just RNC-ID.

Configuration for network sharing is accomplished by defining:

•	NRI in the SGSN service configuration mode

•	PLMN IDs and RNC IDs in the IuPS configuration mode

•	Equivalent PLMN IDs and configured in the Call-Control Profile configuration mode.

•	IMSI ranges are defined in the SGSN-Global configuration mode

•	The Call-Control Profile and IMSI ranges are associated in the configuration mode.

For commands and information on network sharing configuration, refer to the Service Configuration Procedures section in the Cisco ASR 5000 Series Serving GPRS Support Node Administration Guide and the command details in the Cisco ASR 5000 Series Command Line Interface Reference.

NPU FastPath

NPU FastPath’s proprietary internal direct tunnel optimizes resource usage and reduces latency when processing GTP-U packets. This proprietary feature is only available on the ASR 5000 SGSN.

Incoming traffic passes through the switch fabric and the routing headers are changed to re-route traffic from the incoming network processing unit (NPU) of the ingress packet processing card directly to the outgoing NPU of the egress packet processing card. This means that intervening NPUs and CPUs are by-passed. This provides the SGSN with router-like latency and increased node signaling capacity.

SGSN NPU FastPath

FastPath is established when both ends of a tunnel are available. Two FastPath flows are established, one for the uplink and one for the downlink direction for a given PDP context. FastPath will temporarily go down or be disengaged so that packets temporarily do not move through FastPath when either an Intra-SGSN RAU or an Iu-Connection Release occurs.

If FastPath cannot be established, the NPU forwards the GTP-U packets to a CPU for processing and they are processed like all other packets.

FastPath can not be established for subscriber PDP sessions if:

•	Traffic Policing and Shaping is enabled.

•	Subscriber Monitoring is enabled.

•	Lawful Intercept (LI) is enabled,

•	IP Source Violation Checks are enabled.

•	GTP-v0 tunnel is established with an GGSN.

For NPU fast path configuration, refer to Enabling NPU Fast Path for GTP-U Processing section of “Service Configuration Procedures” chapter of Cisco ASR 5000 Series Serving GPRS Support Node Administration Guide.

NRPCA - 3G

The SGSN now supports the Network Requested PDP Context Activation (NRPCA) procedure for 3G attachments.

Whenever there is downlink data at the GGSN for a subscriber, but there is no valid context for the already-established PDP address, the GGSN initiates an NRPCA procedure towards the SGSN. Prior to starting the NRPCA procedure, the GGSN either obtains the SGSN address from the HLR or uses the last SGSN address of the subscriber available at the GGSN.

There are no interface changes to support this feature. Support is configured with existing CLI commands (network-initiated-pdp-activation, location-area-list) in the call-control-profile configuration mode and timers (T3385-timeout and max-actv-retransmission) are set in the SGSN service configuration mode. For command details, see the Cisco ASR 5000 Series Command Line Interface Reference

Operator Policy

The non-standard feature is unique to the ASR 5000 SGSN. This feature empowers the carrier with unusual and flexible control to manage functions that aren’t typically used in all applications and to determine the granularity of the implementation of any : to groups of incoming calls or to simply one single incoming call. For details about the feature, its components, and how to configure it, refer to the chapter in this guide.

Important: SGSN configurations created prior to Release 11.0 are not forward compatible. All configurations for SGSNs, with -related configurations that were generated with software releases prior to Release 11.0, must be converted to enable them to operate with an SGSN running Release 11.0 or higher. Your Cisco Representative can accomplish this conversion for you.

Some Features Managed by Operator Policies

The following is a list of some of the features and functions that can be controlled via configuration of Operator Policies:

•	APN Aliasing

•	Authentication

•	Direct Tunnel - for feature description and configuration details, refer to the Direct Tunnel chapter in this guide

•	Equivalent PLMN

•	IMEI Override

•	Intra- or Inter-SGSN Serving Radio Network Subsystem (SRNS) Relocation (3G only)

•	Network Sharing

•	QoS Traffic Policing per Subscriber

•	SGSN Pooling - Gb/Iu Flex

•	SuperCharger

•	Subscriber Overcharging Protection - for feature description and configuration details, refer to the Subscriber Overcharging Protection chapter in this guide.

Overcharging Protection

Overcharging Protection enables the SGSN to avoid overcharging the subscriber if/when a loss of radio coverage (LORC) occurs in a UMTS network. For details and configuration information, refer to the Subscriber Overcharging Protection chapter in this book.

QoS Traffic Policing per Subscriber

Traffic policing enables the operator to configure and enforce bandwidth limitations on individual PDP contexts for a particular traffic class.

Traffic policing typically deals with eliminating bursts of traffic and managing traffic flows in order to comply with a traffic contract.

The SGSN conforms to the DiffServ model for QoS by handling the 3GPP defined classes of traffic, QoS negotiation, DSCP marking, traffic policing, and support for HSDPA/HSUPA.

QoS Classes

The 3GPP QoS classes supported by the SGSN are:

•	Conversational

•

Streaming

•	Interactive

•	Background

The SGSN is capable of translating between R99 and R97/98 QoS attributes.

QoS Negotiation

On PDP context activation, the SGSN calculates the QoS allowed, based upon:

•	Subscribed QoS - This is a per-APN configuration, obtained from the HLR on an Attach. It specifies the highest QoS allowed to the subscriber for that APN.

•	Configured QoS - The SGSN can be configured with default and highest QoS profiles in the configuration.

•	MS requested QoS - The QoS requested by the UE on pdp-context activation.

DSCP Marking

The SGSN performs diffserv code point (DSCP) marking of the GTP-U packets according to allowed-QoS to PHB mapping. The default mapping matches that of the UMTS to IP QoS mapping defined in 3GPP TS 29.208.

The SGSN also supports DSCP marking of the GTP control plane messages on the Gn/Gp interface. This allows QoS to be set on GTP-C messages, and is useful if Gn/Gp is on a less than ideal link. DSCP marking is configurable via the CLI, with default = Best Effort Forwarding.

Traffic Policing

The SGSN can police uplink and downlink traffic according to predefined QoS negotiated limits fixed on the basis of individual contexts - either primary or secondary. The SGSN employs the Two Rate Three Color Marker (RFC2698) algorithm for traffic policing. The algorithm meters an IP packet stream and marks its packets either green, yellow, or red depending upon the following variables:

•	PIR - Peak Information Rate (measured in bytes/second)

•	CIR - Committed Information Rate (measured in bytes/second)

•	PBS - Peak Burst Size (measured in bytes)

•	CBS - Committed Burst Size (measured in bytes)

The following figure depicts the working of the TCM algorithm:

TCM Algorithm Logic for Traffic Policing

For commands and more information on traffic policing configuration, refer to the Cisco ASR 5000 Series Command Line Interface Reference.

Reordering of SNDCP N-PDU Segments

The SGSN fully supports reordering of out-of-order segments coming from the same SNDCP N-PDU. The SGSN waits the configured amount of time for all segments of the N-PDU to arrive. If all the segments are not received before the timer expiries, then all queued segments are dropped.

Session Recovery

Session recovery provides a seamless failover and reconstruction of subscriber session information in the event of a hardware or software fault that prevents a fully attached user session from having the PDP contexts removed or the attachments torn down.

Session recovery is performed by mirroring key software processes (e.g., session manager and AAA manager) within the system. These mirrored processes remain in an idle state (in standby-mode) until they may be needed in the case of a software failure (e.g., a session manager task aborts). The system spawns new instances of “standby mode” session and AAA managers for each active control processor (CP) being used.

As well, other key system-level software tasks, such as VPN manager, are performed on a physically separate packet processing card to ensure that a double software fault (e.g., session manager and VPN manager fail at the same time on the same card) cannot occur. The packet processing card used to host the VPN manager process is in active mode and is reserved by the operating system for this sole use when session recovery is enabled.

The additional hardware resources required for session recovery include a standby System Management Card and a standby packet processing card.

There are two modes for Session Recovery.

•

Task recovery mode: One or more session manager failures occur and are recovered without the need to use resources on a standby packet processor card. In this mode, recovery is performed by using the mirrored “standby-mode” session manager task(s) running on active packet processor cards. The “standby-mode” task is renamed, made active, and is then populated using information from other tasks such as AAA manager.

•

Full packet processing card recovery mode: Used when a packet processing card hardware failure occurs, or when a packet processor card migration failure happens. In this mode, the standby packet processor card is made active and the “standby-mode” session manager and AAA manager tasks on the newly activated packet processor card perform session recovery.

Session/Call state information is saved in the peer AAA manager task because each AAA manager and session manager task is paired together. These pairs are started on physically different packet processor cards to ensure task recovery.

When session recovery occurs, the system reconstructs the following subscriber information:

•	Data and control state information required to maintain correct call behavior

•	Subscriber data statistics that are required to ensure that accounting information is maintained

•	A best-effort attempt to recover various timer values such as call duration, absolute time, and others

For more information on session recovery use and session recovery configuration, refer to the Session Recovery chapter in the Cisco ASR 5000 Series System Administration Guide.

SGSN Pooling and Iu-Flex / Gb-Flex

This implementation allows carriers to load balance sessions among pooled SGSNs, to improve reliability and efficiency of call handling, and to use Iu-Flex / Gb-Flex to provide carriers with deterministic failure recovery.

The SGSN, with its high capacity, signaling performance, and peering capabilities, combined with its level of fault tolerance, delivers many of the benefits of Flex functionality even without deploying SGSN pooling.

As defined by 3GPP TS 23.236, the SGSN implements Iu-Flex and Gb-Flex functionality to facilitate network sharing and to ensure SGSN pooling for 2.5G and 3G accesses as both separate pools and as dual-access pools.

SGSN pooling enables the following:

•	Eliminates the single point of failure between an RNC and an SGSN or between a BSS and an SGSN.

•	Ensures geographical redundancy, as a pool can be distributed across sites.

•	Minimizes subscriber impact during service, maintenance, or node additions or replacements.

•	Increases overall capacity via load sharing across the SGSNs in a pool.

•	Reduces the need/frequency for inter-SGSN RAUs. This substantially reduces signaling load and data transfer delays.

•	Supports load redistribution with the SGSN offloading procedure.

Gb/Iu Flex Offloading

The SGSN supports Gb/Iu Flex subscriber offloading from one SGSN to another specific SGSN in a 2G/3G pool.

In addition, the operator can configure the offloading Target NRI in P-TMSI, and the quantity to offload to the Target. This can be used to provide load balancing, or to offload a single node in pool, take it out of service for whatever reason (e.g., maintenance).

Short Message Service (SMS over Gd)

The SGSN implements a configurable Short Message Service (SMS) to support sending and receiving text messages up to 140 octets in length. The SGSN handles multiple, simultaneous messages of both types: those sent from the MS/UE (SMS-MO: mobile originating) and those sent to the MS/UE (SMS-MT: mobile terminating). Short Message Service is disabled by default.

After verifying a subscription for the PLMN’s SMS service, the SGSN connects with the SMSC (short message service center), via a Gd interface, to relay received messages (from a mobile) using MAP-MO-FORWARD-REQUESTs for store-and-forward.

In the reverse, the SGSN awaits messages from the SMSC via MAP-MT-FORWARD-REQUESTs and checks the subscriber state before relaying them to the target MS/UE.

The SGSN will employ both the Page procedure and MNRG (mobile not reachable for GPRS) flags in an attempt to deliver messages to subscribers that are absent.

The SGSN supports

•	charging for SMS messages, and

•	lawful intercept of SMS messages

.

For information on configuring and managing the SMS, refer to the SMS Service Configuration Mode chapter in the Cisco ASR 5000 Series Command Line Interface Reference.

SMS Authentication Repetition Rate

The SGSN provides an authentication procedures for standard GMM events like Attach, Detach, RAU, and Service-Request, and SMS events such as Activate, all with support for 1-in-N Authenticate functionality. The SGSN did not provide the capability to authenticate MO/MT SMS events.

Now, the authentication functionality has been expanded to the Gs interface where the SGSN now supports configuration of the authentication repetition rate for SMS-MO and SMS-MT, for every nth event. This functionality is built on existing SMS CLI, with configurable MO and/or MT. The default is not to authenticate.

SMSC Address Denial

Previously, the SGSN supported restricting MO-SMS and MT-SMS only through SGSN operator policy configuration.

Now, the SGSN can restrict forwarding of SMS messages to specific SMSC addresses, in order to allow operators to block SMS traffic that cannot be charged for. This functionality supports multiple SMSCs and is configurable per SMSC address with a maximum of 10 addresses. It is also configurable for MO-SMS and/or MT-SMS messages.

Threshold Crossing Alerts (TCA) Support

Thresholding on the system is used to monitor the system for conditions that could potentially cause errors or outage. Typically, these conditions are temporary (i.e high CPU utilization, or packet collisions on a network) and are quickly resolved. However, continuous or large numbers of these error conditions within a specific time interval may be indicative of larger, more severe issues. The purpose of thresholding is to help identify potentially severe conditions so that immediate action can be taken to minimize and/or avoid system downtime.

The system supports Threshold Crossing Alerts for certain key resources such as CPU, memory, number of sessions etc. With this capability, the operator can configure threshold on these resources whereby, should the resource depletion cross the configured threshold, a SNMP Trap would be sent.

The following thresholding models are supported by the system:

•	Alert: A value is monitored and an alert condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of the polling interval.

•	Alarm: Both high and low threshold are defined for a value. An alarm condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of the polling interval.

Thresholding reports conditions using one of the following mechanisms:

•	SNMP traps: SNMP traps have been created that indicate the condition (high threshold crossing and/or clear) of each of the monitored values.

Generation of specific traps can be enabled or disabled on the chassis. Ensuring that only important faults get displayed. SNMP traps are supported in both Alert and Alarm modes.

•	Logs: The system provides a facility called threshold for which active and event logs can be generated. As with other system facilities, logs are generated Log messages pertaining to the condition of a monitored value are generated with a severity level of WARNING.

Logs are supported in both the Alert and the Alarm models.

•

Alarm System: High threshold alarms generated within the specified polling interval are considered “outstanding” until a the condition no longer exists or a condition clear alarm is generated. “Outstanding” alarms are reported to the system's alarm subsystem and are viewable through the Alarm Management menu in the Web Element Manager.

The Alarm System is used only in conjunction with the Alarm model.

Important: For more information on threshold crossing alert configuration, refer to the Thresholding Configuration Guide.

Tracking Usage of GEA Encryption Algorithms

GPRS encryption algorithm (GEA) significantly affects the SGSN processing capacity based on the GEAx level used - GEA1, GEA2, or GEA3.

Operators would like to be able to identify the percentages of their customer base that are using the various GEA encryption algorithms. The same tool can also track the migration trend from GEA2 to GEA3 and allow an operator to forecast the need for additional SGSN capacity.

New fields and counters have been added to the output generated by the show subscribers gprs-only|sgsn-only summary command. This new information enables the operator to track the number of subscribers capable of GEA0-GEO3 and to easily see the number of subscribers with negotiated GEAx levels.

VLR Pooling via the Gs Interface

VLR Pooling, also known as Gs Pooling, helps to reduce call delays and call dropping, when the MS/UE is in motion, by routing a service request to a core network (CN) node with available resources.

VLR pools are configured in the Gs Service, which supports the Gs interface configuration for communication with VLRs and MSCs.

A pool area is a geographical area within which an MS/UE can roam without the need to change the serving CN node. A pool area is served by one or more CN nodes in parallel. All the cells, controlled by an RNC or a BSC belong to the same one (or more) pool area(s).

VLR hash is used when a pool of VLRs is serving a particular LAC (or list of LACs). The selection of VLR from this pool is based on the IMSI digits. From the IMSI, the SGSN derives a hash value (V) using the algorithm: [(IMSI div 10) modulo 1000]. Every hash value (V) from the range 0 to 999 corresponds to a single MSC/VLR node. Typically many values of (V) may point to the same MSC/VLR node.

For commands to configure the VLR and pooling, refer to the “Gs Service Configuration Mode” chapter in the Cisco ASR 5000 Series Command Line Interface Reference.

How the SGSN Works

This section illustrates some of the GPRS mobility management (GMM) and session management (SM) procedures the SGSN implements as part of the call handling process. All SGSN call flows are compliant with those defined by 3GPP TS 23.060.

First-Time GPRS Attach

The following outlines the setup procedure for a UE that is making an initial attach.

Simple First-Time GPRS Attach

This simple attach procedure can connect an MS via a BSS through the Gb interface (2.5G setup) or it can connect a UE via a UTRAN through the Iu interface in a 3G network with the following process:

First-Time GPRS Attach Procedure

Step	Description
1	The MS/UE sends an Attach Request message to the SGSN. Included in the message is information, such as: • Routing area and location area information • Mobile network identity • Attach type
2	Authentication is mandatory if no MM context exists for the MS/UE: • The SGSN gets a random value (RAND) from the HLR to use as a challenge to the MS/UE. • The SGSN sends a Authentication Request message to the UE containing the random RAND. • The MS/UE contains a SIM that contains a secret key (Ki) shared between it and the HLR called a Individual Subscriber Key. The UE uses an algorithm to process the RAND and Ki to get the session key (Kc) and the signed response (SRES). • The MS/UE sends a Authentication Response to the SGSN containing the SRES.
3	The SGSN updates location information for the MS/UE: a) The SGSN sends an Update Location message, to the HLR, containing the SGSN number, SGSN address, and IMSI. b) The HLR sends an Insert Subscriber Data message to the “new” SGSN. It contains subscriber information such as IMSI and GPRS subscription data. c) The “New” SGSN validates the MS/UE in new routing area: If invalid: The SGSN rejects the Attach Request with the appropriate cause code. If valid: The SGSN creates a new MM context for the MS/UE and sends a Insert Subscriber Data Ack back to the HLR. d) The HLR sends a Update Location Ack to the SGSN after it successfully clears the old MM context and creates new one
4	The SGSN sends an Attach Accept message to the MS/UE containing the P-TMSI (included if it is new), VLR TMSI, P-TMSI Signature, and Radio Priority SMS. At this point the GPRS Attach is complete and the SGSN begins generating M-CDRs.

‌

If the MS/UE initiates a second call, the procedure is more complex and involves information exchanges and validations between “old” and “new” SGSNs and “old” and “new” MSC/VLRs. The details of this combined GPRS/IMSI attach procedure can be found in 3GPP TS23.060.

PDP Context Activation Procedures

The following figure provides a high-level view of the PDP Context Activation procedure performed by the SGSN to establish PDP contexts for the MS with a BSS-Gb interface connection or a UE with a UTRAN-Iu interface connection.

Call Flow for PDP Context Activation

The following table provides detailed explanations for each step indicated in the figure above.

PDP Context Activation Procedure

Step	Description
1	The MS/UE sends a PDP Activation Request message to the SGSN containing an Access Point Name (APN).
2	The SGSN sends a DNS query to resolve the APN provided by the MS/UE to a GGSN address. The DNS server provides a response containing the IP address of a GGSN.
3	The SGSN sends a Create PDP Context Request message to the GGSN containing the information needed to authenticate the subscriber and establish a PDP context.
4	If required, the GGSN performs authentication of the subscriber.
5	If the MS/UE requires an IP address, the GGSN may allocate one dynamically via DHCP.
6	The GGSN sends a Create PDP Context Response message back to the SGSN containing the IP Address assigned to the MS/UE.
7	The SGSN sends a Activate PDP Context Accept message to the MS/UE along with the IP Address. Upon PDP Context Activation, the SGSN begins generating S-CDRs. The S-CDRs are updated periodically based on Charging Characteristics and trigger conditions. A GTP-U tunnel is now established and the MS/UE can send and receive data.

‌

Network-Initiated PDP Context Activation Process

In some cases, the GGSN receives information that requires it to request the MS/UE to activate a PDP context. The network, or the GGSN in this case, is not actually initiating the PDP context activation -- it is requesting the MS/UE to activate the PDP context in the following procedure:

Network-Initiated PDP Context Activation

The table below provides details describing the steps indicated in the graphic above.

Network Invites MS/UE to Activate PDP Context

Step	Description
1	The GGSN receives a PDU with a static PDP address that the GGSN ‘knows’ is for an MS/UE in its PLMN.
2	The GGSN uses the IMSI in place of the PDP address and sends an SRI (send routing information for GPRS) to the HLR. The HLR sends an SRI response back to the GGSN. The response may include the access of the target SGSN and it may also indicate it the MS/UE is not reachable, in which case it will include the reason in the response message.
3	The GGSN sends a PDU Notification Request to the SGSN (if the address was received). If the address was not received or if the MS/UE continues to be unreachable, the GGSN sets a flag marking that the MS/UE was unreachable. The notified SGSN sends a PDU Notification Response to the GGSN.
4	The SGSN determines the MS/UE’s location and sets up a NAS connection with the MS/UE. The SGSN then sends a Request PDP Context Activation message to the MS/UE.
5	If the MS/UE accepts the invitation to setup a PDP context, the MS/UE then begins the PDP context activation process indicated in the preceding procedure.

‌

MS-Initiated Detach Procedure

This process is initiated by the MS/UE for a range of reasons and results in the MS/UE becoming inactive as far as the network is concerned.

MS-Initiated Combined GPRS/IMSI Detach

The following table provides details for the activity involved in each step noted in the diagram above.

MS-Initiated Combined GPRS/IMSI Detach Procedure

Step	Description
1	The UE sends a Detach Request message to the SGSN containing the Detach Type, P-TMSI, P-TMSI Signature, and Switch off indicator (i.e. if UE is detaching because of a power off).
2	The SGSN sends Delete PDP Context Request message to the GGSN containing the TEID. The GGSN sends a Delete PDP Context Response back to the SGSN. The SGSN stops generating S-CDR info at the end of the PDP context.
3	The SGSN sends a IMSI Detach Indication message to the MSC/VLR.
4	The SGSN sends a GPRS Detach Indication message to the MSC/VLR. The SGSN stops generating M-CDR upon GPRS Detach.
5	If the detach is not due to a UE switch off, the SGSN sends a Detach Accept message to the UE.
6	Since the UE GPRS Detached, the SGSN releases the Packet Switched Signaling Connection.

‌

Supported Standards

The SGSN services comply with the following standards for GPRS/UMTS wireless data services.

IETF Requests for Comments (RFCs)

•	RFC-1034, Domain Names - Concepts and Facilities, November 1987; 3GPP TS 24.008 v7.8.0 (2007-06)

•	RFC-1035, Domain Names - Implementation and Specification, November 1987; 3GPP TS 23.003 v7.4.0 (2007-06)

•	RFC-2960, Stream Control Transmission Protocol (SCTP), October 2000; 3GPP TS 29.202 v6.0.0 (2004-12)

•	RFC-3332, MTP3 User Adaptation Layer (M3UA), September 2002; 3GPP TS 29.202 v6.0.0 (2004-12)

•	RFC-4187, Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA), January 2006

•	RFC-4666, signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA), September 2006; 3GPP TS 29.202 v6.0.0 (2004-12)

3GPP Standards

Release 6 and higher is supported for all specifications unless otherwise noted. For higher releases indicated below, current and planned development is aiming towards full compliance with the releases listed below:

•	3GPP TS 9.60 v7.10.0 (2002-12), 3rd Generation Partnership Project; Technical Specification Group Core Network; General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface (R98).

•	3GPP TS 22.041 v8.1.0 (2007-06), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Operator Determined Barring (ODB) (Release 8)

•	3GPP TS 23.007 v7.0.0 3rd Generation Partnership Project; Technical Specification Group Core Network; Restoration procedures (Release 7)

•	3GPP TS 23.015 v7.0.0 (2007-03), 3rd Generation Partnership Project; Technical Specification Group Core Network; Technical realization of Operator Determined Barring (ODB) (Release 7)

•	3GPP TS 23.016 v7.0.0 (2007-06), 3rd Generation Partnership Project; Technical Specification Group Core Network; Subscriber data management; Stage 2 (Release 7

•	3GPP TS 23.040 v7.2.0 (2009-03), 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Technical realization of the Short Message Service (SMS) (Release 7)

•	3GPP TS 23.060 v7.10.0 (2010-09), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS); Service description; Stage 2

•	3GPP TS 23.078 v7.10.0 (2009-09), 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 4; Stage 2 (Release 7)

•	3GPP TS 23.107 v7.0.0 (2007-06), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Quality of Service (QoS) concept and architecture

•	3GPP TS 23.236 v7.0.0 (2006-12), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Intra-domain connection of Radio Access Network (RAN) nodes to multiple Core Network (CN) nodes (Release 7)

•	3GPP TS 23.251 v7.0.0 (2007-06), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Network Sharing; Architecture and functional description

•	3GPP TS 24.007 v7.0.0 (2005-09), 3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile radio interface signalling layer 3; General aspects (Release 7)

•	3GPP TS 24.008 v7.10.0 (2007-12), 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (Release 7)

•	3GPP TS 25.410 v7.0.0 (2006-03), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu Interface: general aspects and principles (Release 7)

•	3GPP TS 25.411 v7.0.0 (2006-03) and (2007-06), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface layer 1 (Release 7)

•	3GPP TS 25.412 v7.1.0 (2006-06), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface signaling transport (Release 7)

•	3GPP TS 25.413 v6.14.0 (2007-06), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface RANAP signaling; some features support v7.6.0 (2007-06)

•	3GPP TS 25.414 v7.1.0 (2006-06), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface data transport and transport signaling

•	3GPP TS 25.415 v6.3.0 (2006-06), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface user plane protocols

•	3GPP TS 29.002 v6.15.0 (2006-12), 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mobile Application Part (MAP) specification

•	3GPP TS 29.016 v6.0.0 (2004-12), 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Serving GPRS Support Node SGSN - Visitors Location Register (VLR); Gs Interface Network Service Specification

•	3GPP TS 29.018 v6.5.0 (2006-12), 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; General Packet Radio Service (GPRS); Serving GPRS Support Node (SGSN) - Visitors Location Register (VLR) Gs interface layer 3 specification

•	3GPP TS 29.060 v6.17.0 (2007-06), 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface

•	3GPP TS 29.202 v8.0.0 (2007-06), 3rd Generation Partnership Project; Technical Specification Group Core Network; SS7 signaling Transport in Core Network; Stage 3

•	3GPP TS 32.215 v5.9.0 (2007-10), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Charging management; Charging data description for the Packet Switched (PS) domain

•	3GPP TS 32.251 v7.4.0 (2007-10), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Charging management; Packet Switched (PS) domain charging

•	3GPP TS 32.298 v7.4.0 (2007-10), 3rd Generation Partnership Project; Technical Specification Group Service and System Aspects; Telecommunication management; Charging management; Charging Data Record (CDR) parameter description

•	3GPP TS 32.406 v8.0.0 (2008-12), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Performance Management (PM); Performance measurements Core Network (CN) Packet Switched (PS) domain (Release 8)

•	3GPP TS 32.410 v9.0.0 (2009-10), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Key Performance Indicators (KPI) for UMTS and GSM (Release 9)

•	3GPP TS 33.102 v6.5.0 (2005-12), Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects;3G Security; Security architecture

•	3GPP TS 44.064 v7.1.0 (2007-03), 3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile Station - Serving GPRS Support Node (MS-SGSN); Logical Link Control (LLC) layer specification

•	3GPP TS 44.065 v7.0.0 (2006-09), 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mobile Station (MS) - Serving GPRS Support Node (SGSN); Subnetwork Dependent Convergence Protocol (SNDCP) (Release 7)

•	3GPP TS 48.014 v7.3.0 (2006-12), 3rd Generation Partnership Project; Technical Specification Group GSM EDGE Radio Access Network; General Packet Radio Service (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN) interface; Gb Interface

•	3GPP TS 48.016 v7.3.0 (2006-12), 3rd Generation Partnership Project; Technical Specification Group GSM EDGE Radio Access Network; General Packet Radio Service (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN) interface; Network Service

•	3GPP TS 48.018 v7.10.0 (2007-06), 3rd Generation Partnership Project; Technical Specification Group GSM/EDGE Radio Access Network; General Packet Radio Service (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN); BSS GPRS Protocol (BSSGP)

•	Appendix 1: SGSN-TRS_QoS-3GPP Standards

ITU Standards

•	Q711; 3GPP TS 29.002 v6.15.0 (2007-12), 3GPP TS 29.016 v7.0.0 (2007-08), and 3GPP TS 25.410 v7.0.0 (2006-03)

•	Q712; 3GPP TS 29.002 v6.15.0 (2007-12), 3GPP TS 29.016 v7.0.0 (2007-08), and 3GPP TS 25.410 v7.0.0 (2006-03)

•	Q713; 3GPP TS 29.002 v6.15.0 (2007-12), 3GPP TS 29.016 v7.0.0 (2007-08), and 3GPP TS 25.410 v7.0.0 (2006-03)

•	Q714; 3GPP TS 29.002 v6.15.0 (2007-12), 3GPP TS 29.016 v7.0.0 (2007-08), and 3GPP TS 25.410 v7.0.0 (2006-03)

•	Q715; 3GPP TS 29.002 v6.15.0 (2007-12), 3GPP TS 29.016 v7.0.0 (2007-08), and 3GPP TS 25.410 v7.0.0 (2006-03)

•	Q716; 3GPP TS 29.002 v6.15.0 (2007-12), 3GPP TS 29.016 v7.0.0 (2007-08), and 3GPP TS 25.410 v7.0.0 (2006-03)

•	Q771; 3GPP TS 29.002 v6.15.0 (2007-12)

•	Q772; 3GPP TS 29.002 v6.15.0 (2007-12)

•	Q773; 3GPP TS 29.002 v6.15.0 (2007-12)

•	Q774; 3GPP TS 29.002 v6.15.0 (2007-12)

•	Q775; 3GPP TS 29.002 v6.15.0 (2007-12)

Object Management Group (OMG) Standards

•	CORBA 2.6 Specification 01-09-35, Object Management Group

 

 

Cisco Systems Inc.

Tel: 408-526-4000

Fax: 408-527-0883